1. Field of the Invention
The invention relates to the design of electronic circuits and more particularly to methods for visualizing constraints in electronic circuit designs.
2. Description of the Related Art
Electronic Design Automation (EDA) tools allow circuit designers to define constraints on the objects in a circuit design, such as transistors and wires. A constraint is associated with one or more design objects, and may represent relationships among design objects. For example, in the context of the EDA domain, constraints are ordinarily associated with design objects such as devices, pins, terminals, instance terminals, and interconnect wires to represent design parameters for the design objects, and to represent relationships or requirements imposed by the design specification on the objects.
Constraints allow designers to bring consistency into the design flow and achieve structures which are known to the designer to be viable, but which sometimes cannot be directly captured in design parameters, and which are generally beyond the process design rules. For instance, constraints help reduce second-order effects such as parasitics and increase the chance that a design will meet design specifications in a small number of design iterations. A simple constraint example is that of symmetry: when two symmetrically constrained objects are placed in a circuit layout, they generally should be placed symmetrically (about some axis) with respect to each other. Effectively, one object has to be the mirror image of the other. The symmetrical placement greatly increases the chances of these devices operating more identically in a practical integrated circuit manufacturing process that tends to include variations from one device to the next. Symmetrical placement is used to reduce the manufacturing variations, and is one of many constraint relationships that can be used to achieve high yielding, well-performing designs.
With the increasing complexity of circuit design technology, concepts such as constraint-driven, connectivity-driven, and design rule-aware layout have been adopted by EDA tools in both the integrated circuit and printed circuit board domains. This capability allows multiple designers to encode and respect design constraints at various stages of design flow, ensure correct connectivity, and prevent design rule errors automatically. However, smaller geometries, growth in complexity, design rules, and constraints all contribute to a deluge of information—too much to be managed manually.
To address the increasing number of constraints, a mechanism may be used to manage constraints from a central location and distribute them to different tools. However, as constraints may store and depict relationships between design objects, these constraint relationships often are not presented in a manner that makes such relationships readily apparent. In particular, constraints often are portrayed in a manner that does not sufficiently aid the designer in visualizing the relationships imposed. This inability to readily perceive what constraints have been annotated on the design may result in a designer's decision to run through and iterate on the design's physical realization in order to understand the constraint.
Thus, there is a need for an effective visualization mechanism that allows design constraints to be effectively visualized on the design canvas along with the design objects to illustrate relationships between objects or groups of objects so as to facilitate analysis and understanding of the circuit, even when the constraints are not being used to drive automated tools. The design objects should be clearly visible and accurately displayed along with the constraints. Visualization is especially important for analog designs, where sizes, shapes, spacing, and relative positioning of design objects in the circuit layout are especially important.
Prior approaches to visualizing constraints have involved the use of table-based widgets, which display the names of constraints and the names of design objects associated with the constraints in a tree or table format. These have been appreciated by users and are effective in listing constraints and their members. However, often this list is very long and difficult to unravel, and as constraint names are insufficient by themselves, a mental leap is required to locate the corresponding constraint members in the design. In addition, as the constraint relationships are not specially rendered or visualized on the canvas, the table-based widget approach also requires the designers to simultaneously keep track of the location and orientation of the actual design object and its proximity to other objects during interactive design editing. This problem becomes more severe as the number of design constraints increases, making it more difficult for the designer to manually locate the design objects and then keep track of them.
FIG. 1A is an illustrative drawing of circuit design objects highlighted according to a prior highlighting method. In FIG. 1A, an EDA application is displaying two constraints, named Constr_0 and Constr_5, which are being visualized on the design canvas using a prior highlighting method. A Constr_0 text label 150 is displayed in the same color as the design object(s) 154 associated with the constraint Constr_0. Similarly, a Constr_5 text label 168 is displayed in the same color as the design objects 156, 162 associated with the constraint Constr_5. In the prior method, each constrained design object, e.g., diode or transistor, is displayed in a highlight color, which is generally a unique color associated with a single constraint. Temporary objects such as textual annotations and shapes, also drawn in the highlight color, are also used to impart special meaning to the highlighted objects. Highlighting makes it easier to keep track of the constraint design objects, even while interactive design edits are being done. As highlighting allows the use of multiple colors, it is even possible to visualize different types of constraints in different colors.
Unfortunately, there have been shortcomings with prior constraint highlighting techniques. For example, in the above prior method, highlighting occurs on a separate graphics drawing plane over, i.e., above, the drawing plane used for rendering the design objects. Therefore, the prior highlighting approach often causes the actual device shapes to be obscured. If there are additional highlight objects (e.g., textual annotations for constraint and member names) in use to impart special meaning to highlighted design objects, they too obscure the visible design areas. This is often a problem when the constraint has to be visualized for a prolonged duration. Further, an attempt to highlight an object associated with multiple constraints in more than one color generally causes the object to be highlighted with the last applied color, which makes it difficult for the designer to see what other constraints apply to a design object. Moreover, the prior highlighting method typically draws the highlighted object shape in the same width as the un-highlighted object, which is often too narrow to visually stand out. Other limitations include the inability to visualize other forms of interconnection between devices (or group relationships) in a way that does not obscure the spatial and electrical relationships. The prior technique also fails to adequately show relationships that involve objects not displayed in the current view, such as relationships between objects on different levels of the design hierarchy. For example, a relationship that matches a transistor at the top level with a transistor several levels down a schematic hierarchy may coerce logic designers into either unnecessarily flattening a hierarchy or moving a first device which should be placed at a certain level for logical or electrical reasons to some other level so that the first device can be spatially close to a second device on the other level to which its properties are to be closely matched.
With reference to the prior highlighting method of FIG. 1A, if multiple constraints are associated with a single design object, the design object will be displayed in only one of the colors. Therefore, the circuit designer will not see a visual indication that multiple constraints are associated with a single design object. For example, the association of the label Constr_5 with two diodes 156, 162 is represented by changing the color of the diodes 156, 162 to the same color as the constraint Constr_5 text label 168. If the Constr_5 text label 168 is displayed in blue, then the diodes 156, 162 may be displayed in blue to indicate that Constr_5 is associated with the diodes 156,162. If a second constraint ConstrO of a different type than Constr_5 is also associated with the diodes 156,162, then the color of the diodes 156,162 will again be changed to the color associated with Constr_0, replacing the color associated with Constr_5, so that at most one associated constraint is visualized at a time. Note that changing the colors of the design objects interferes with the appearance of the circuit design and may result in loss of information or confusion. If the original, non-highlighted color of the design object conveys visual information about that design object, then replacing the color will result in loss of that visual information.
Other visual aspects of the prior highlighting method typically interfere with the appearance of the circuit design. The displayed design objects may be obscured and modified by, for example, rectangular boxes drawn around the devices to indicate association with a constraint. The constraint names, such as Constr_0, may overlap and obscure portions of the displayed design objects. For example, the constraint name Constr_0 partially overlaps a solder dot 166 near the transistor 154, and the constraint name Constr_5 partially overlaps a wire 152, thereby partially obscuring the wire 152.
Thus, there is a need for improved constraint visualization in the Electronic Design Automation context. The present invention meets the need.